На одном из блогов о виртуализации на платформе VMware появилась интересная утилита VLANidentificator, предоставляющая информацию о принадлежности всех ваших виртуальных машин к портгруппам виртуальных коммутаторов и их VLAN ID:
Вы просто вводите стартовый IP-адрес и подсеть для сканирования, а скрипт пробегается по всем хостам VMware ESXi и vCenter, после чего все данные помещаются в сводную таблицу, в которой вы можете проверить, что нужные машины находятся в нужных VLAN, а также посмотреть на каких хостах ESXi они сейчас размещены. Для показа полной информации о машине, в том числе IP-адреса, нужно чтобы в ВМ были установлены VMware Tools.
Утилитка требует PowerShell 3 и более поздней версии и протестирована для работы с VMware vSphere 5.0, поэтому с шестой версией вполне может не работать. Поддерживаются также и распределенные виртуальные коммутаторы VMware Distributed Switch (vDS).
Исполняемый файл VLANidentificator можно скачать по этой ссылке. Ну а исходный код можно скачать вот тут.
Как многие из вас знают, в состав платформы виртуализации VMware vSphere 6.0 входит виртуальный модуль VMware vCenter Server Appliance (vCSA) 6.0, который реализует все необходимые сервисы управления виртуальной инфраструктурой в виде уже готовой виртуальной машины на базе Linux.
По умолчанию в данном модуле настроено устаревание пароля в 90 дней, и если в течение этого времени он не был сменен, он устареет и не будет работать. То есть, через три месяца вы увидите вот такую картинку:
Unable to authenticate user. Please try again.
В этом случае вам нужно либо сбросить пароль vCenter Server Appliance и установить новый, либо (если вы помните старый пароль , но он устарел) разлочить аккаунт.
Делается это вот каким образом:
1. Используем какой-нибудь Linux LiveCD (например, KNOPPIX).
Подключаем ISO-шку к виртуальной машине с vCSA и загружаемся с нее в Shell:
Затем повышаем привилегии командой:
# su -
2. Монтируем файловую систему vCSA с помощью команды:
# mount /dev/sda3 /mnt
3. Создаем резервную копию файла с паролем рута и открываем его для редактирования:
# cd /mnt/etc
#
cp shadow shadow.bak
# vi /mnt/etc/shadow
Видим определение пароля root:
4. Если вы помните пароль, а он просто устарел:
В этом случае просто удаляем букву x (выделена желтым) и цифру 1 (также желтая - останется два двоеточия). Нажмите клавишу <i>, чтобы перейти в режим редактирования. После того, как вы внесете нужные изменения, нажмите <esc> и потом напишите ZZ, после чего нажмите ввод, чтобы сохранить изменения.
После перезагрузки vCSA старый пароль root будет работать.
5. Если вы не помните пароль:
Надо заменить его хэш. Сначала смотрим, что стоит в начале строчки. У вас, скорее всего, будет там $6$, что означает, что это хэш, сгенерированный по алгоритму SHA512. От правого доллара конструкции $6$ и до следующего доллара в этой строчке идет так называемая "соль" - это значение вам надо записать на бумажке или сфотать (доллары в него не входят).
Далее генерируем новый пароль, используя записанную соль, следующей командой:
# mkpasswd -m sha-512 <новый пароль> <соль>
Потом получившийся пароль просто вставляем в файл /etc/shadow, который вы только что открывали. Вставляем его от правого доллара, ограничивающего соль, до первого двоеточия. Тут плоховато видно, но суть понятна, куда вставлять этот пароль:
После перезагрузки vCSA вы можете логиниться в него с новым паролем.
Напомним, что Magic Quadrant используется для оценки поставщиков какого-либо сегмента рынка информационных технологий, где Gartner использует две линейные прогрессивные экспертные шкалы:
полнота видения (completeness of vision)
способность реализации (ability to execute)
Каждый поставщик, попавший в рамки рассмотрения для исследуемого сегмента рынка, оценивается по этим двум критериям. При этом, полнота видения откладывается на оси абсцисс, способность реализации — на оси ординат. Каждый поставщик, таким образом, оказывается в одном из четырёх квадрантов плоскости, называемых:
Лидеры (leaders) — поставщики с положительными оценками как по полноте видения, так и по способности реализации.
Претенденты (сhallengers) — поставщики с положительными оценками только по способности реализации.
Провидцы (visionaries) — поставщики с положительными оценками только по полноте видения.
Нишевые игроки (niche players) — поставщики с отрицательными оценками по обоим критериям.
В этом году квадрант выглядит так:
Что мы видим? Два явных лидера, VMware и Microsoft, и кучка лузеров, застенчиво сбившихся в тесный кут нишевых игроков. В хвосте уныло плетется Huawei. Кстати, не удивляйтесь новому названию Odin - это теперь так называется сервис-провайдерский бизнес Parallels (с продуктами Virtuozzo, Plesk и другими).
Ну а вот так выглядел квадрант Gartner в сфере серверной виртуализации в 2014 году:
Oracle тогда еще считали способным что-то сделать, но почему-то в последние пару лет чуваки из Oracle вообще забили на серверную виртуализацию (например, вот наша заметка про VirtualBox, который ждал обновления почти 5 лет).
Ну и для информации - квадранты прошлых лет (когда еще Citrix подавала надежды):
Таким образом, рынок серверной виртуализации, можно сказать, уже окончательно сформировался и его в чем-то можно сравнить с мобильным рынком: VMware - это Apple рынка виртуализации (дорого, но хорошо сделано), а Microsoft - это Google (дешево, но не понятно, куда тыкать и зачем). Хороша ли такая ситуация?
Интересный сервис по продвижению решения Virtual SAN предлагает компания VMware через своих партнеров. Поскольку сам продукт стоит очень дорого, и мало кого можно на него подписать вот так вот сразу, VMware предлагает воспользоваться услугой VSAN Assessment. Она бесплатна, может быть оказана любым партнером VMware и позволяет получить необходимую конфигурацию аппаратного обеспечения для консолидации существующих виртуальных машин в отказоустойчивых кластерах Virtual SAN (напомним, что емкость там формируется из емкости локальных дисков серверов, являющихся узлами кластеров VSAN).
Суть сервиса такова: партнер регистрирует в закрытой партнерской секции новое обследование инфраструктуры (VSAN Assessment), после чего отправляет инвайт на него потенциальному заказчику. Он, в свою очередь, скачивает готовый виртуальный модуль (Collector Appliance), настраивает его и держит запущенным в течение, по крайней мере, одной недели (минимально).
В течение этого времени происходит сбор профилей рабочей нагрузки по вводу-выводу, на основании чего можно уже нарисовать необходимые ресурсы кластера хранилищ, выбрать нужную модель сервера для узла VSAN и определить требуемое число таких узлов.
Сначала анализируется виртуальная инфраструктура VMware vSphere на площадке клиента:
Затем выводятся рекомендуемые к консолидации в кластере хранилищ виртуальные машины. Также показывается совместимость с типом кластера Virtual SAN (All-flash или гибридная модель, где данные размещаются на магнитных накопителях):
Затем мы видим требуемые ресурсы как для одного узла, так и для всего кластера Virtual SAN, а также видим, какой именно сервер и с какими аппаратными характеристиками имеется в виду (производителя сервера можно выбрать, само собой):
Ну и для того, чтобы заказчика отвлечь от высокой входной цены продукта Virtual SAN, используется метод убеждения по снижению совокупной стоимости владения (TCO - total cost of ownership) при внедрении решения VMware VSAN:
Ну и прямо расписывают вам экономию по годам:
Ну то есть, если вы все же решили потестировать технологию VMware Virtual SAN, обратитесь к своему поставщику - он заведет вам VSAN Assessment и вы сами посмотрите, какие железки рекомендуется использовать именно под ваши нагрузки по вводу-выводу для размещения виртуальных машин.
Есть такая штука в сфере ИБ - Security banner. Это когда при логине в какую-нибудь консоль вы выводите пользователю сообщение о характере информации и системы, к которой он пытается получить доступ, и предупреждаете о возможной ответственности за несанкционированный доступ. Вряд ли это много кого остановит, но все же с ним лучше, чем без него.
Вот способ сделать security banner для VMware ESXi. В VMware vSphere он бывает двух видов:
1. Login banner
Это текст, который показывается после ввода имени пользователя, но до ввода пароля:
Чтобы его поменять нужно залогиниться на хост VMware ESXi и с помощью редактора vi или nano отредактировать следующий файл:
# vi /etc/issue
Нажмите клавишу <i>, чтобы перейти в режим редактирования. После того, как вы внесете нужные изменения, нажмите <esc> и потом напишите ZZ, после чего нажмите ввод, чтобы сохранить изменения. Затем перезагрузите демон SSH следующей командой:
# /etc/init.d/SSH restart
2. Баннер MOTD.
Это баннер, который показывают пользователю после успешного логина по SSH. Чтобы задать его (по умолчанию он пустой), нужно отредактировать следующий файл через vi:
# vi /etc/motd
Также можно не лазить на хост VMware ESXi, а открыть vSphere Web Client, перейти в Manage->Settings и в разделе Advanced System Settings поискать по строчке "etc.". Там будет 2 параметра:
Config.Etc.issue - это текст для security banner
Config.Etc.motd - текст для баннера motd
То же самое можно сделать и в толстом клиенте vSphere Client:
Наши постоянные читатели помнят, что еще в 2009 году компания VMware анонсировала Project Onyx, предназначенный для записи действий пользователя в клиенте vSphere и их перекладывания на язык сценариев PowerShell. Также какое-то время назад на сайте проекта VMware Labs появилась утилита Onyx, которая проксировала команды от vSphere Client к серверу vCenter и записывала их как PowerCLI-скрипт (сейчас ее страница переехала вот сюда).
Ну а на днях компания VMware выпустила техническое превью Onyx for the Web Client, который уже позволяет начать запись действий пользователя и получить готовый сценарий прямо в веб-клиенте vSphere.
После установки Onyx for the Web Client появится иконка утилиты в домашнем меню веб-клиента:
Далее просто нажимаем кнопку записи (Start), после чего выполняем нужные нам действия в Web Client:
И получаем на выходе готовый сценарий для исполнения того же самого действия через PowerCLI:
Полученный сценарий можно сохранить:
Классная штука и просто находка для тех, кто хочет все автоматизировать в своей виртуальной инфраструктуре. Скачать Onyx for the Web Client можно по этой ссылке. Инструкции по установке находятся здесь. Поставить его можно как на vCenter Server Appliance, так и на vCenter Server для Windows.
Помните некоторое время назад мы писали о новой версии решения для виртуализации настольных ПК предприятия VMware Horizon View 6.1.1, в которую были добавлены такие полезные функции, как Client Drive Redirection и поддержка десктопов с ОС Linux?
На днях один из администраторов VMware Horizon опубликовал диаграмму портов и соединений этого решения, так как оно за последние годы значительно разрослось и требует некоторой настройки нужных правил на корпоративных сетевых экранах.
Собственно, кликабельная диаграмма:
Основные рекомендации по настройке фаерволов для VMware Horizon View:
TCP/UDP 4173: PCoIP-порт, используемый для хостов RDS.
TCP 4002: порт режима JMS enhanced security mode (SSL).
TCP 5443: слушающий порт для протокола Blast для прямых соединений с Linux-десктопами (требует наличия Horizon Client версии 3.3 или более поздней).
TCP 8443: слушающий порт для протокола Blast для соединений с Linux-десктопами через Blast Secure Gateway (требует наличия Horizon Client версии 3.3 или более поздней).
TCP 8472: интерфейс коммуникации между кластерами View в архитектуре Cloud Pod (interpod API).
TCP 22389: коммуникация Global ADLDS (также для Cloud Pod).
HTTPS (443): доступ для Horizon Client - аутентификация и RDP-туннель (HTTPS Secure Gateway).
HTTPS (8443): используется для HTML 5 доступа к виртуальным ПК Linux. HTML-доступ к ПК с ОС Linux официально не поддерживается, хотя большинство браузеров работают.
HTTPS (22443): HTML-доступ по протоколу Blast для виртуальных ПК с ОС Windows.
TCP 9427: используется механизмами Windows Multimedia Redirection (MMR) и Client Drive Redirection (CDR).
ESP Protocol (порт 50): используется для серверов Security Server и Connection Server при защищенной коммуникации IPSEC (требует включенного Windows firewall с опцией Advanced Security).
UDP 500: коммуникация IPsec для Security Server и Connection Server при создании пары.
Мы уже писали про издание технического характера VMware Technical Journal (VMTJ), которое представляет собой периодический журнал о различного рода проблемах, которые рассматриваются научными и инженерными сотрудниками компании VMware. Некоторое время назад этот проект переехал на портал VMware Labs, посвященный различного рода разработкам, облегчающим пользователям работу с продуктами в сфере виртуализации на платформах VMware. Также там есть и ресурсы, касающиеся VMware Academic Program.
Журнал VMTJ выходит два раза в год - зимой и летом, сейчас пока доступен только зимний номер этого года (69 страниц), но к концу лета должен подоспеть и следующий.
Статьи больше похожи на научные труды - это не посты о том, как какой-нибудь VMware NSX настраивать, а более глубокие и абстрактные исследования:
FlashStream: A Multitiered Storage Architecture in Data Centers for Adaptive HTTP Streaming
Reducing Cache-Associated Context-Switch Performance Penalty Using Elastic Time Slicing
The Role of Social Graph in Content Discovery Within Enterprise Social Networking
NoETL: ETL Code Generation for a Dimensional-Data Warehouse
A Framework for Secure Offline Authentication and Key Exchange Between Mobile Devices
Just-in-Time Desktops and the Evolution of VDI
Connectivity and Collaboration in VMware vCloud Suite
Directions in Mobile Enterprise Connectivity
В конце каждой статьи идет внушительный список использованной литературы. Всего с 2012 года было выпущено 6 неморов журнала VMTJ. Вот ссылки на предыдущие выпуски:
Время от времени у пользователей VMware vSphere возникает ошибка, связанная с тем, что виртуальный диск VMDK виртуальной машины оказывается залоченным (то есть эксклюзивно используемым процессом VMX одного из хостов ESXi). В этом случае виртуальная машина не отвечает на попытки включить ее или переместить на другой хост-сервер средствами VMware vMotion. При этом процесс vmx вполне может быть запущен не на том хосте ESXi, на котором машина отображается в VMware vSphere Client или Web Client. Такое может случиться при падении хоста ESXi, массовом отключении питания или неполадках в сети SAN, а также и в некоторых других случаях.
Например, может быть вот такое сообщение об ошибке при включении машины:
Could not power on VM: Lock was not free
Для решения проблемы вам нужно найти хост ESXi, который исполняет vmx-процесс машины, и убить ВМ, которая не отвечает. После этого можно будет использовать VMDK-файл этой машины, а также включить ее, если она не работает.
Делается это следующим образом:
1. Находим хост, исполняющий vmx-процесс виртуальной машины с залоченным VMDK.
Для этого заходим по SSH на один из серверов ESXi (эта процедура работает для версий vSphere 5.5 P05 и 6.0, а также более поздних) и переходим в папку /bin:
#cd /bin
С помощью утилиты vmfsfilelockinfo ищем владельца лока нужного VMDK-файла:
Здесь vm1.vmdk - наш залоченный виртуальный диск, а 192.168.1.10 - IP-адрес сервера VMware vCenter. Вам потребуется ввести пароль его администратора.
Вывод будет примерно таким:
vmfsflelockinfo Version 1.0
Looking for lock owners on "VM1_1-000001-delta.vmdk"
"VM1_1-000001-delta.vmdk" is locked in Exclusive mode by host having mac address ['00:50:56:03:3e:f1']
Trying to make use of Fault Domain Manager
----------------------------------------------------------------------
Found 0 ESX hosts using Fault Domain Manager.
----------------------------------------------------------------------
Could not get information from Fault domain manager
Connecting to 192.168.1.10 with user administrator@vsphere.local
Password: xXxXxXxXxXx
----------------------------------------------------------------------
Found 3 ESX hosts from Virtual Center Server.
----------------------------------------------------------------------
Searching on Host 192.168.1.178
Searching on Host 192.168.1.179
Searching on Host 192.168.1.180
MAC Address : 00:50:56:03:3e:f1
Host owning the lock on the vmdk is 192.168.1.180, lockMode : Exclusive
Total time taken : 0.27 seconds.
Из вывода можно понять 2 важные вещи:
MAC-адрес хоста, залочившего VMDK
IP-адрес хоста, залочившего VMDK
Тип лока - Exclusive
Кстати, лок может быть нескольких типов:
mode 0 - нет лока
mode 1 - эксклюзивный лок (vmx-процесс машины существует и использует VMDK-диск)
mode 2 - лок только для чтения (например, для основного диска, в случае если у него есть снапшоты)
mode 3 - лок для одновременной записи с нескольких хостов (например, для кластеров MSCS или ВМ, защищенных технологией VMware Fault Tolerance).
2. Точно определяем хост, машина которого держит VMDK.
Если IP-адрес показан - хост определен. Если, мало ли, по какой-то причине его нет, можно ориентироваться на MAC-адрес. Выяснить его можно следующей командой на хосте ESXi:
# vim-cmd hostsvc/net/info | grep "mac ="
3. Обнаруживаем процесс VMX, который держит VMDK.
Выполняем на найденном ESXi команду:
# lsof | egrep 'Cartel|vm1.vmdk'
Получаем что-то вроде этого:
Cartel | World name | Type | fd | Description
36202 vmx FILE 80 /vmfs/volumes/556ce175-7f7bed3f-eb72-000c2998c47d/VM1/vm1.vmdk
Мы нашли Cartel ID нужного процесса VMX (36202). Теперь выполняем команду, чтобы найти ее World ID:
# esxcli vm process list
Получаем такой вывод:
Alternate_VM27
World ID: 36205
Process ID: 0
VMX Cartel ID: 36202
UUID: 56 4d bd a1 1d 10 98 0f-c1 41 85 ea a9 dc 9f bf
Display Name: Alternate_VM27
Config File: /vmfs/volumes/556ce175-7f7bed3f-eb72-000c2998c47d/Alternate_VM27/Alternate_VM27.vmx
Alternate_VM20
World ID: 36207
Process ID: 0
VMX Cartel ID: 36206
UUID: 56 4d bd a1 1d 10 98 0f-c1 41 85 ea a5 dc 94 5f
Display Name: Alternate_VM20
Config File: /vmfs/volumes/556ce175-7f7bed3f-eb72-000c2998c47d/Alternate_VM20/Alternate_VM20.vmx
...
Видим, что World ID нашей машины - 36205.
4. Убиваем VMX-процесс, залочивший VMDK.
Ну и убиваем зависший процесс VMX следующей командой:
# esxcli vm process kill --type force --world-id <ID>
После этого с машиной и ее диском можно делать уже что требуется.
Также для более ранних версий VMware vSphere посмотрите нашу статью вот здесь.
Если вы администратор платформы виртуализации VMware vSphere, то, наверное, часто замечали, что в некоторых случаях при операциях с виртуальными машинами и ее дисками происходит "подмораживание" ВМ (или "stun", он же "quiescence"). В этот момент виртуальная машина ничего не может делать - она недоступна для взаимодействия (в консоли и по сети), а также перестает на небольшое время производить операции ввода-вывода. То есть, ее исполнение ставится на паузу на уровне инструкций, а на уровне ввода-вывода совершаются только операции, касающиеся выполняемой задачи (например, закрытие прежнего VMDK-диска и переключение операций чтения-записи на новый диск при операциях со снапшотами).
Cormac Hogan написал на эту тему интересный пост. Stun виртуальной машины нужен, как правило, для того, чтобы сделать ее на время изолированной от окружающего мира для выполнения значимых дисковых операций, например, консолидация снапшотов. Это может занимать несколько секунд (и даже десятков), но часто это происходит на время около секунды и даже меньше.
Когда может возникать stun виртуальной машины? Есть несколько таких ситуаций.
1. Во время операции "suspend" (постановка ВМ на паузу). Тут происходит такое подмораживание, чтобы скинуть память ВМ на диск, после чего перевести ее в приостановленное состояние.
2. В момент создания снапшота. Об этом написано выше - нужно закрыть старый диск и начать писать в новый. На время этой операции логично, что приостанавливается ввод-вывод.
3. Консолидация снапшотов (удаление всех). Здесь тоже нужно "склеить" все VMDK-диски (предварительно закрыв) и начать работать с основным диском ВМ. А вот удаление снапшота в цепочке stun не вызывает, так как не затрагивает VMDK, в который сейчас непосредственно идет запись.
4. Горячая миграция vMotion. Сначала память передается от одной машины к целевой ВМ без подмораживания, но затем происходит такой же stun, как и при операции suspend, с тем только отличием, что маленький остаток памяти (минимальная дельта) передается не на диск, а по сети. После этого происходит операция resume уже на целевом хосте. Пользователь этого переключения, как правило, не замечает, так как время этого переключения очень жестко контролируется и чаще всего не достигает 1 секунды. Если память гостевой ОС будет меняться очень быстро, то vMotion может затянуться именно во время этого переключения (нужно передать последнюю дельту).
5. Горячая миграция хранилищ Storage vMotion. Здесь stun случается аж дважды: сначала vSphere должна поставить Mirror Driver, который будет реплицировать в синхронном режиме операции ввода-вывода на целевое хранилище. При постановке этого драйвера происходит кратковременный stun (нужно также закрыть диски). Но и при переключении работы ВМ на второе хранилище происходит stun, так как нужно удалить mirror driver, а значит снова переоткрыть диски уже на целевом хранилище.
В современных версиях vSphere работа со снапшотами была оптимизирована, поэтому подмораживания виртуальной машины во время этих операций вы почти не заметите.
Скоро компания Код Безопасности представит публичный коммерческий релиз решения vGate R2 версии 2.8, а пока вы можете посмотреть ролик о том, как именно данный продукт обеспечивает защиту виртуальных сред VMware vSphere и Microsoft Hyper-V. Ролик достаточно технический и наглядный - из него реально можно узнать, как работает продукт и отдельные его функции:
В ролике раскрываются следующие темы, касающиеся решения vGate R2:
Обзор архитектуры и функциональности продукта
Рабочий процесс при взаимодействии администраторов виртуальной инфраструктуры и администраторов информационной безопасности
Режимы работы (новое!) и централизованное управление
Усиленная аутентификация администраторов
Мандатный контроль доступа
Контроль целостности
Просмотр событий и работа с отчетами
Поддержка распределенных инфраструктур (vCenter Linked Mode) и выгрузка конфигурации
Давно мы не публиковали сравнений платформ виртуализации VMware vSphere и Microsoft Hyper-V, которые, как известно, лишены смысла (ибо они либо ангажированы, либо сравнивают мягкое с горячим, либо привязываются к конкретному варианту использования). Всем понятно, что VMware - это дорогая и мощная платформа для тех у кого есть деньги, а Microsoft - бюджетная платформа виртуализации серверов в небольших компаниях. И в ближайшие пару лет это вряд ли изменится.
Так вот, оказывается, одно из последних сравнений VMware vSphere 5.1 и Microsoft Hyper-V третьей версии (примерно то, что есть сейчас) мы публиковали аж в 2012 году. Но ведь не так давно компания VMware обновила свое сравнение, включив туда VMware vSphere 6.0, пытаясь, видимо, широко распространить эту презентацию до того, как Microsoft обновит свой Windows Server до платформы vNext (это будет в следующем году).
Ну а мы, без зазрения совести, публикуем здесь это сравнение.
Итак, основные параметры платформ (гипервизора). VMware действительно выигрывает по Enterprise-фичам, но все довольно спорно для SMB:
Обеспечение доступности и защита данных. Здесь VMware, конечно же, впереди. Но нужен ли такой уровень доступности (например, Fault Tolerance) для небольших компаний? Иногда да, но чаще выгоднее сэкономить.
Автоматизация и управление. Ну вот это все точно про крупную организацию:
Ну и традиционный булшит про стоимость владения (его как бы можно посчитать на калькуляторе VMware вот тут). Когда не могут оправдать высокую входную цену продукта - берутся, как правило, заливать про TCO. Типа автоматизация сэкономит вам кучу денег:
Как, помимо прочего, происходит экономия при виртуализации? Типа, говорят, становится меньше дел, и можно сократить "лишних" системных администраторов. На деле же геморроя становится больше, поэтому администратора приходится нанимать.
Как многие из вас знают, в VMware vSphere 6.0 была добавлена функциональности горячей миграции vMotion виртуальной машины между датацентрами под управлением разных серверов vCenter. Виртуальные машины могут теперь перемещаться между виртуальными коммутаторами Standard vSwitch и Distributed Switch (vDS)в любой их комбинации, при этом при уходе с vDS настройки машины на его портах сохраняются и уезжают вместе с ней.
На днях VMware выпустила интересное видео, описывающее данную возможность:
Чтобы машина могла переезжать с одного vCenter на другой в горячем режиме необходимо:
Чтобы оба сервера vCenter были версии 6.0 или более поздней.
Чтобы оба сервера vCenter работали в режиме Enhanced Linked Mode и были в одном домене Single Sign-On, то есть один vCenter (исходный) мог аутентифицироваться на другом (целевом).
Оба сервера vCenter должны быть синхронизированы по времени, чтобы SSO мог корректно производить аутентификацию.
Если вы переносите только ВМ с сервера на сервер (хранилище остается тем же), оба сервера vCenter должны видеть общее хранилище (соответственно, хост-серверы и vCenter должны быть соответствующим образом отзонированы).
Больше подробностей можно узнать из видео выше и KB 2106952.
На сайте проекта VMware Labs появилась очередная полезная утилита - View Auto-Connection Utility, которая может понадобиться администраторам виртуальной инфраструктуры десктопов VMware View. Эта штука позволяет задать параметры соединения с виртуальным ПК, протестировать их и включить возможность автосоединения с конкретным десктопом:
Утилита обнаруживает установленный VMware View Client на компьютере, после чего можно выбрать следующие параметры:
Подключение к виртуальному ПК или отдельному приложению по RDSH
Сервер Connection Server и пул виртуальных ПК
Протокол (PCoIP или RDP)
Логин/пароль
Режим отображения консоли (полный экран или в окне)
Подключить USB-устройства
Отключить Shade (верхняя часть меню в консоли виртуального ПК)
Также можно сгенерировать консольную команду по запуску клиента, настроить выход из приложения по окончанию сессии и отключить предупреждения клиента (Launch Silently).
Протестив соединение с помощью кнопки Test Connection, можно поставить галку "Enable AutoConnection" и добавить программу в автозагрузку. После этого, при старте физического ПК сразу будет запускаться нужное соединение с виртуальным десктопом. Очень просто и полезно, особенно для тонких клиентов (или для превращение компьютеров в "как бы тонкие клиенты").
В качестве хостовых ОС поддерживаются следующие:
Windows XP
Windows 7
Windows Vista
Windows 8
Windows 8.1
Windows Server 2003
Windows Server 2008
Windows Server 2012
Скачать View Auto-Connection Utility можно по этой ссылке. Инструкции по использованию доступны здесь.
Практически все администраторы виртуальных инфраструктур обеспокоены проблемой ее производительности в тех или иных условиях. На днях компания VMware обновила свое основное руководство по производительности платформы виртуализации номер один на рынке - Performance Best Practices for VMware vSphere 6.0.
Это не просто очередной whitepaper - это настоящая книга о производительности, на почти 100 страницах которой можно найти не только теоретические советы, но и вполне практичные настройки и конфигурации среды VMware vSphere. К каждому объясняемому параметру заботливо описаны рекомендуемые значения. В общем, Must Read.
Документ состоит из двух частей: в первой части рассказывается о том, как правильно спроектировать кластер vMSC и настроить платформу VMware vSphere соответствующим образом:
Во второй части подробно описаны различные сценарии сбоев и их обработка кластером vMSC в вашей распределенной виртуальной инфраструктуре:
В документе описаны следующие виды сбоев:
Отказ одного хоста в основном датацентре
Изоляция одного хоста в основном датацентре
Разделение пула виртуальных хранилищ
Разделение датацентра на сегменты (сети хостов и сети хранилищ)
Отказ дисковой полки в основном ЦОД
Полный отказ всех хранилищ в основном датацентре
Потеря устройств (полный выход из строя, выведение из эксплуатации) - Permanent Device Loss (PDL)
Понятное дело, что документ обязателен к прочтению, если вы планируете строить распределенную инфраструктуру для ваших виртуальных машин на платформе VMware vSphere 6.0.
Цель документа - дать понятие о методике сбора данных об ИТ-окружении, сайзинге, планировании архитектуры и внедрении VMware Mirage в инфраструктуру предприятия. Напомним, что сам Horizon Mirage предназначен для управления образами виртуальных и физических ПК на уровне слоев ОС, приложений и данных (это нужно для обновлений компонентов, бэкапа и восстановления, а также миграции ОС в корпоративной инфраструктуре).
Пояснения к работе схемы:
Каждый конечный ПК (виртуальный или физический) содержит установленный клиент Mirage, которые забирает слои (ОС, приложения, данные) с серверов Mirage (или кластера этих серверов).
Администраторы определяют расписание и проводят обновления этих слоев.
При изменении слоя на конечном ПК происходит синхронизация этих изменений в сторону датацентра, чтобы обе копии окружений были одинаковыми (этот процесс может инициировать как пользователь, так и администратор датацентра).
Если подумываете о внедрении Horizon Mirage, то документ, конечно же, нужно обязательно прочитать.
В самом конце прошлого года мы писали о том, что компания VMware выпустила решение VMware Horizon FLEX, которое представляло собой продолжение продуктов VMware ACE (если его здесь кто-то еще помнит) и VMware View Local Mode. Напомним, что Horizon FLEX представляет собой платформу виртуализации для настольных ПК, позволяющую запускать виртуальные ПК локально (как на Mac во Fusion, так и на Windows в Player), без требования связи с датацентром компании. Кстати, VMware Mirage входит в состав VMware FLEX.
На днях компания VMware анонсировала обновление Horizon FLEX 1.5:
Теперь в продукте появилось много новых функций и возможностей (большинство доработок основано на фидбэке пользователей), а именно:
больше новых политик - больше гибкости в настройке
возможность удаленно стереть виртуальную машину с хоста
более гибкий и гранулярный контроль политик для USB-устройств
управление на базе политик для файловой системы хоста и ВМ
больше возможностей по выделению машине оперативной памяти и CPU
интеграция с Active Directory по зашифровке/расшифровке виртуального образа
возможность задания лимита на запуск только одной копии ВМ
иконка для виртуальной машины пользователя на рабочем столе
Скорее всего, вам будет лень все это ставить, поэтому пройдемся по данному решению в формате видеообзоров. Об основных функциях продукта:
Создание образа для пользователей:
Настройка политик для виртуальной машины, которая уйдет к пользователю для локального запуска:
В блоге Tech Communications Video Blog компании VMware в последние дни появилось три действительно интересных видеоролика. Во-первых, вы знаете, что в последней версии VMware Horizon View 6.1.1 появилась поддержка виртуальных десктопов Linux.
Директор по R&D в видео ниже рассказывает, как они работают, а также показывает весь процесс, включая консольные команды и настройку параметров. То есть, это не маркетинговый булшит, а хороший технический обзор новой функции, в которой заинтересованы сейчас многие:
Во-вторых, весьма интересен ролик про различие параметров настройки vCenter Server Appliance версий 5.5 и 6.0 (в шестой версии больше нет Virtual Appliance Management Interface):
Ну и, в-третьих, полезно посмотреть видео о развертывании продукта VMware vRealize Business Standard, являющегося частью пакета решений VMware vCloud Suite 6.0. Напомним, что vRealize Business нужен для автоматического определения стоимости содержания и развития инфраструктуры, а также измерения потребления ресурсов.
Да и в общем и целом блог весьма интересный для технической аудитории - посмотрите прошлые видео.
В блоге компании VMware появился интересный пост с некоторыми подробностями о работе технологии репликации виртуальных машин vSphere Replication. Приведем здесь основные полезные моменты.
Во-первых, репликация с точки зрения синхронизации данных, бывает двух типов:
Full sync - это когда требуется полная синхронизация виртуальной машины и всех ее дисков в целевое местоположение. Для этого в версии VMware vSphere 5.x использовалось сравнение контрольных сумм дисков на исходном и целевом хранилище. Если они не совпадают, и нужно делать Full sync, исходя из начальных условий - начинается процесс полной репликации ВМ. В первую очередь, основным подвидом этого типа является Initial full sync - первичная синхронизация работающей виртуальной машины, для которой репликация включается впервые.
Кроме того, полная синхронизация включается, когда по какой-либо причине произошла ошибка отслеживания блоков виртуального диска машины при дельта-репликации и передать на целевую ВМ только изменения виртуальных дисков становится невозможным.
Delta sync - после того, как полная синхронизация закончена, начинается процесс передачи целевой ВМ только различий с момента полной репликации. Тут используется технология changed block tracking, чтобы понять, какие блоки надо отреплицировать с последнего Full sync. Периодичность дельта-репликации зависит от установленной политики Recovery Point Objective (RPO).
Чтобы политика RPO соблюдалась нужно, чтобы дельта-синхронизация полностью проходила за половину времени, установленного в RPO, иначе будут нарушения политики, сообщения о которых вы увидите в vSphere Client. Почему половину? Подробно мы писали об этом вот тут (почитайте, очень интересно). Также еще и в документации VMware есть информация о расписании репликации.
Если вы настроите репликацию для виртуальной машины, то автоматически работать она будет для включенной ВМ, а если она выключена, то сама работать не будет, о чем будет выдано соответствующее предупреждение:
Вот так запускается репликация для выключенной ВМ:
Во время offline-репликации виртуальную машину нельзя включить, а ее диски будут залочены. Кроме того, вы не сможете отменить эту операцию. Поэтому при нажатии Sync Now будет выведено вот такое предупреждение:
Обычно offline-репликация используется для создания гарантированной копии ВМ на другой площадке (например, при переезде датацентра или частичном восстановлении инфраструктуры на другом оборудовании). Ну или если у вас была настроена online-репликация, а вы выключили ВМ, то в конце нужно сделать еще ручной Sync Now.
Также в VMware vSphere 6.0 было сделано существенное улучшение в производительности процесса репликации. Если раньше идентичность копий основного диска и реплики сверялась только на базе контрольных сумм (все данные диска надо прочитать - а это затратно по вводу-выводу и CPU), то теперь иногда используются данные о конфигурации виртуального диска на базе регионов. Например, если на исходном диске есть регионы, которые не были аллоцированы на целевом диске, то репликация это отслеживает и передает данные в эти регионы на целевое хранилище. Это работает значительно быстрее вычисления контрольных сумм.
Но такая оптимизация работает не для всех типов виртуальных дисков, а только для Lazy zeroed thick disks, thin disks и vSAN sparse disks и только на томах VMFS. Тома NFS, тома VVols, а также диски типа Eager zeroed thick не предоставляют информации об аллокации регионов, поэтому для них оптимизация работать не будет. Более подробно об этом написано тут.
Дункан опубликовал в своем блоге интересный пост про то, как кластер VMware Virtual SAN размещает данные больших VMDK-дисков на малых физических дисках. Напомним, что Virtual SAN оперирует понятием дисковых страйпов (disk stripes), на которые разбивается дисковый объект (в частности, виртуальный диск VMDK является дисковым объектом). Это как кирпичики Virtual SAN, на уровне которых работает кластер.
Давайте взглянем на картинку:
Здесь мы видим вот что: на уровне политики (VSAN Policy) задан параметр "Number of failures to tolerate" (подробнее об этом мы писали тут) равный 1. Это значит, что инфраструктура Virtual SAN может пережить отказ не более одного хоста.
Но также в рамках политики есть еще и параметр "Stripe Width" (он же "Number of Disk Stripes Per Object"), который позволяет разбить дисковый объект на два страйпа: stripe/a и stripe/b, причем обратите внимание, что реплика дискового объекта может храниться на разных хост-серверах (а может и на одном - это вы никак не сможете отрегулировать, гарантируется лишь, что это будут 2 разных hdd-диска). Так что, если у вас маленькие диски, а виртуальные машины с большими дисками VMDK, то задайте этот параметр вот здесь:
Кстати говоря, объекты разбиваются на страйпы не только при заданном Stripe Width, но и автоматически, когда размер VMDK превышает 256 ГБ.
Как некоторые из вас знают, компания VMware в последний год активно двигает продажи не просто платформы VMware vSphere, а ее "расширенной" версии со средствами мониторинга и управления (есть даже пакеты Acceleration Kit с обязательной добавкой Operations Management). По-сути, vSphere with Operations Management - это vSphere плюс vRealize Operations Standard.
Помните про такой сайт VMware Walkthroughs, где собраны обучающие интерактивные материалы, с помощью которых можно виртуально "пощупать" продукты VMware, в частности vSphere и Virtual SAN? Так вот недавно этот ресурс пополнился материалами про vSphere with Operations Management.
Теперь всем желающим доступны материалы на следующие темы об Operations Management:
Не так давно мы писали о том, что компания VMware выпустила бета-версию своего основного руководства по обеспечению информационной безопасности виртуальной инфраструктуры vSphere 6.0 Hardening Guide. На днях же вышла финальная версия этого документа. Надо отметить, что документ весьма сильно поменялся по структуре и содержанию:
Согласно записи в блоге VMware, в данной версии руководства были сделаны следующие позитивные изменения:
Сделан упор на автоматизацию воплощения рекомендаций через API, чтобы доставить меньше хлопот по ручному конфигурированию настроек. Приводятся конкретные команды PowerCLI и vCLI для исследования конфигураций и задания необходимых параметров.
В качестве рекомендуемого значения добавлен параметр "site-specific", что означает, что конкретная имплементация данной настройки зависит от особенностей инфраструктуры пользователя.
Появилась колонка с разносторонним обсуждением проблемы потенциальной уязвимости (с учетом предыдущего пункта).
Дается больше информации о потенциальных рисках - на что влияет данная настройка в итоге.
Кстати, вот полный список руководящих документов по обеспечению безопасности других продуктов компании VMware и прошлых версий VMware vSphere:
Ну и надо обязательно добавить, что VMware Configuration Manager теперь полностью поддерживает конфигурации из руководства vSphere 6 Hardening Guide. Более подробно об этом написано в блоге VMware Security.
Многие наши читатели интересуются, а есть ли утилиты, предназначенные специально для облачных инфраструктур. Например, которые позволяют оценить качество предоставления услуг сервис-провайдером? Да, есть такое, и одно из подобных средств - AppEnsure - как раз позволяет измерять время отклика для корпоративных приложений и текущую используемую пропускную способность.
Теперь это полноценный продукт, с платным и бесплатным изданиями, который позволяет анализировать качество предоставления услуг облаком (частным или публичным) и искать причину падения производительности приложений.
Вот возможности бесплатной версии AppEnsure:
Обнаружение приложений вашей инфраструктуры и их добавление в окружение мониторинга.
Автоматическое построение топологии зависимости компонентов вашего приложения.
Измерение по шагам (hop-by-hop) и полного (end-to-end) времени отклика, а также пропускной способности канала для каждого приложения.
Возможность предоставления диагностической информации при снижении пропускной способности или увеличении времени отклика.
Продукт AppEnsure (консоль и база данных) поставляется как готовый виртуальный модуль (VMware Virtual Appliance).
Доступны как серверные, так и десктопные агенты для ОС Windows/Linux (до 5 серверов в бесплатной версии).
Поддержка удаленных агентов (в другой сети или облаке по отношению к мастер-инсталляции).
Доступ к веб-порталу технической поддержки.
Сохранение данных в течение 24 часов (в платной версии - сколько угодно).
Вот так выглядит обнаруженная топология:
Так дэшборд приложения:
А вот так - общий дэшборд:
Ну и таблица сравнения изданий:
Загрузить бесплатную версию AppEnsure или попробовать платную версию продукта можно по этой ссылке.
В нескольких заметках мы освещали новости о продукте VMware Log Insight, который предназначен для автоматизированного управления файлами журналов, а также сбора различных данных, их анализа и поиска.
Многие администраторы VMware vSphere знают, что такой продукт есть, на мало кто знает, зачем он реально нужен. Ну да, централизованно собирает логи, есть аналитика, но когда он может пригодиться? Поэтому приведем тут пример решения конкретной административной задачи с помощью VMware Log Insight, которую описал у себя в блоге Iwan Rahabok.
Итак, каждый из вас, я надеюсь, знает, что снапшоты виртуальных машин - это плохо (назовем их "snapshits"). Поэтому в большой инфраструктуре часто оказывается необходимым найти тех, кто снапшоты создает, а если он потом их удалил, то когда это было сделано.
Для начала создадим и удалим снапшот виртуальной машины. Это отобразится в списке последних задач vSphere Web Client:
Откроем консоль VMware Log Insight и перейдем в представление "Virtual Machine – Snapshots", как показано ниже:
Видим, что оба события были пойманы. Переключимся в представление Interactive Analytics (в верхнем меню):
Тут мы видим оба события на таймлайне. Расширим диапазон до 7 дней и добавим фильтр по строчкам "vmw_esxi_snapshot_operation". Видим записи лога о снапшотах:
Ну и переключимся на вкладку Field Table, где выберем параметр vc_username в качестве фильтра (если пользователь заходил из vCenter):
Ну и видим тут, что всеми этими делами занимался пользователь obi-wan.
На самом деле, с помощью Log Insight можно вытягивать очень много чего полезного, например, можно было бы составить фильтр так, чтобы показать виртуальные машины только по указанному шаблону именования.
Контейнерная виртуализация и специализированные облака — тренд нашего времени. Возможность выпускать приложение в унифицированном формате под любую платформу привлекательна сама по себе. А если добавить сюда открытость, поддержку всех основных систем виртуализации и фокус на разработчиков ПО, то получаем любопытное решение для поставщиков программного обеспечения и их клиентов. В этой статье поговорим о платформенном облаке Pivotal CF и поищем ответ на вопрос, зачем оно нужно.
Компания Pivotal — обособленное подразделение EMC, кoторое разрабатывает продукты для виртуализации и облачных вычислений. Наиболее известным из них можно назвать Pivotal Cloud Foundry, который предназначен для упрощения жизни разработчикам ПО. Pivotal предлагает некую абстракцию для всем привычной IaaS-виртуализации, когда ПО выпускается в виде своеобразного «строительного кубика» без привязки к платформе виртуализации. Напоминает контейнеры, правда? По сути идея очень близка, но имеет свои особенности.
Теперь любой разработчик может запустить свое приложение в среде Cloud Foundry, выбрав конкретное облако по желанию: vSphere, AWS или OpenStack. Подход сулит серьезную экономию времени и сил на предоставлении доступа заказчикам к новым разработкам. А возможность работы с облаками нескольких типов еще больше повышают гибкость и решения.
Платформенное облако
Pivotal CF — платформа для облачных систем, которая выступает в качестве некоего слоя абстракции для виртуальной среды (как виртуализация для виртуализации). Суть в том, чтобы создать унифицированную площадку, на которой можно запускать любые приложения без привязки к конкретному облаку или гипервизору. То есть строительным блоком служит не виртуальная машина, а контейнер приложения. На контейнерах подробнее остановимся чуть позже, а пока разберемся, чем CF лучше привычного облака PaaS.
Platform as a Service (PaaS) — модель предоставления облачных вычислений, при которой потребитель получает доступ к использованию информационно-технологических платформ: операционных систем, систем управления базами данных, связующему программному обеспечению, средствам разработки и тестирования, размещённым у облачного провайдера.
Фактически Pivotal предлагает прийти к любому облачному провайдеру с собственным облаком-платформой, которое ставится поверх всех популярных IaaS. Зачем нужно так усложнять и почему бы просто не создать десяток VM на той же vSphere? Все очень просто: а вдруг вы хотите работать с Amazon, а не VMware? Или нужно распределенное по миру решение, а услуги облачных провайдеров в разных странах отличаются по платформе или цене за нее. В конце концов, можно построить огромное распределенное облако сразу из нескольких типов IaaS и вообще ничем себя не стеснять...[кликните, чтобы читать дальше]
Интересная история произошла тут между компаниями VMware и Nutanix. Инженеры и сейлы из VMware решили провести сравнение производительности программных отказоустойчивых кластеров на базе локальных хранилищ серверов VMware Virtual SAN и Nutanix. Создав тестовую конфигурацию и выбрав профиль нагрузки, компания VMware сделала тест в средах Virtual SAN и Nutanix.
Кстати, вот конфигурация тестового кластера хранилищ:
4 x Dell XC630-10 для Nutanix,
4 x Dell R630 для vSphere с кластером VSAN
2 x Intel E5-2690 v3 на сервер
12 ядер на процессор 2.6GHz, 256 ГБ памяти на сервер
Двухпортовый 10Gb Ethernet
1 x PERC H730 Mini на сервер
2 x 400GB Intel S3700 на сервер
6 дисков x 1TB 7200 RPM NL-SAS (Seagate) на сервер
Но тут спецы из VMware решили заглянуть в EULA Nutanix, а там написано (п. 2.1, подпункт e):
You must not disclose the results of testing, benchmarking or other performance or evaluation information related to the Software or the product to any third party without the prior written consent of Nutanix
То есть, публиковать результаты тестирования нельзя. Вот такой облом. А ведь VMware много раз ругали за то, что она сама запрещает публиковать результаты тестирования производительности с конкурирующими продуктами. Это также зафиксировано в EULA:
You may use the Software to conduct internal performance testing and benchmarking studies. You may only publish or otherwise distribute the results of such studies to third parties as follows: (a) if with respect to VMware’s Workstation or Fusion products, only if You provide a copy of Your study to benchmark@vmware.com prior to distribution; (b) if with respect to any other Software, only if VMware has reviewed and approved of the methodology, assumptions and other parameters of the study (please contact VMware at benchmark@vmware.com to request such review and approval) prior to such publication and distribution.
VMware, конечно, утверждает, что у нее условия мягче, но по-сути у них написано одно и то же. Публиковать результаты тестов без разрешения нельзя. А разрешение, конечно, никто не даст, так как опубликовать конкуренты захотят только, если у них все работает лучше и быстрее.
Поэтому VMware ничего не оставалось, как опубликовать результаты только своих тестов и разбить их по профилям нагрузки, отметив, что желающие сравнить пользователи сами могут убедиться, что Nutanix работает медленнее, проведя тесты самостоятельно.
Надо также отметить, что VMware отправила запрос на публикацию в Nutanix, на что получила ожидаемый ответ - публиковать нельзя.
Ну и, собственно, результаты тестирования для кластера Virtual SAN:
Один из лидеров на рынке резервного копирования и управления виртуальной инфраструктурой, компания Veeam Software, официально объявила о запуске во втором квартале 2015 года новой версии лучшего решения для резервного копирования, репликации и управления виртуальной средой - Veeam Availability Suite v9. Напомним, что о возможностях пакета Veeam Availability Suite v8 мы писали вот тут.
Пока стало известно о двух новых возможностях продукта. А именно:
1. Интеграция с технологией EMC Storage Snapshots в Veeam Availability Suite v9.
Многие пользователи Veeam Backup and Replication задавали вопрос, когда же будет сделана интеграция с дисковыми массивами EMC. Теперь она будет добавлена для СХД линеек EMC VNX и EMC VNXe.
Интеграция с хранилищами EMC означает поддержку обеих техник - Veeam Explorer for Storage Snapshots recovery и Backup from Storage snapshots, то есть можно смотреть содержимое снапшотов уровня хранилища и восстанавливать оттуда виртуальные машины (и другие сущности - файлы или объекты приложений), а также делать бэкап из таких снапшотов.
Иллюстрация восстановления из снапшота на хранилище EMC:
Иллюстрация процесса резервного копирования (Veeam Backup Proxy читает данные напрямую со снапшота всего тома, сделанного на хранилище EMC):
Более подробно об этих возможностях можно почитать в блоге Veeam.
2. Veeam Cloud Connect - теперь с возможностью репликации.
Как вы помните, в прошлом году компания Veeam выпустила средство Veeam Cloud Connect, которое позволяет осуществлять резервное копирование в облако практически любого сервис-провайдера. Теперь к этой возможности прибавится еще и возможность репликации ВМ в облако, что невероятно удобно для быстрого восстановления работоспособности сервисов в случае большой или маленькой беды:
Кстати, Veeam Cloud Connect инкапуслирует весь передаваемый трафик в один-единственный порт, что позволяет не открывать диапазоны портов при соединении с инфраструктурой сервис-провайдера. Очень удобно.
При восстановлении в случае аварии или катастрофы основного сайта, возможно не только полное восстановление инфраструктуры, но и частичное - когда часть продуктивной нагрузки запущено на основной площадке, а другая часть (например, отказавшая стойка) - на площадке провайдера. При этом Veeam Backup обеспечивает сетевое взаимодействие между виртуальными машинами обеих площадок за счет встроенных компонентов (network extension appliances), которые обеспечивают сохранение единого пространства адресации.
Ну а сервис-провайдеры с появлением репликации от Veeam получают в свои руки полный спектр средств для организации DR-площадки в аренду для своих клиентов:
Более подробно о репликации Veeam Cloud Connect рассказано в блоге Veeam. Сам продукт ожидается к выпуску, скорее всего (как сказал Антон Гостев), в третьем квартале 2015 года. Следить за новостями по Veeam Availability Suite v9 можно вот тут.
На прошлой неделе компания VMware без особого шума выпустила обновление своей платформы виртуализации настольных ПК Horizon View 6.1.1. Несмотря на то, что обновление номера версии произошло только в третьем разряде, новых возможностей появилось весьма немало.
Посмотрим на новые функции и улучшения продукта:
Client Drive Redirection
Пользователи теперь могут шарить папки и приводы своих локальных клиентских ПК для удаленных десктопов и приложений. Client Drive Redirection поддерживается для VDI-десктопов и для RDS-десктопов и приложений. Данная фича поддерживается для ОС Windows и в экспериментальном режиме для Mac OS X. Будьте внимательны - файлы, передаваемые по сети, не шифруются!
Десктопы с ОС Linux на базе Horizon 6
Наконец-то. Теперь можно развернуть инфраструктуру View Horizon на базе виртуальных ПК с ОС Linux. Можно поставить View Agent for Linux, где при установке можно задать родительские машины или шаблоны с ОС Ubuntu, RHEL, CentOS или NeoKylin и развернуть пулы виртуальных ПК через View Administrator. Для виртуальных машин Linux поддерживается технология vDGA (на данный момент только для адаптеров NVIDIA GRID GPU). Некоторые возможности, такие как SSO, автоматическое развертывание виртуальных ПК, HTML Access и перенаправление локальных дисков не поддерживаются в этой версии. Больше подробностей тут.
Serial Port Redirection
Теперь пользователи могут перенаправить последовательный порт (COM) RS232 или адаптеры типа USB-to-Serial. Через эти порты можно пробросить старые принтеры, сканеры штрих-кодов и другие legacy или промышленные устройства.
Поддержка Windows Media Multimedia Redirection (MMR) для виртуальных ПК на базе RDS
Ранее эта фича поддерживалась только для виртуальных десктопов VDI, на которых мог работать только один пользователь. Больше подробностей можно узнать в разделе System Requirements for Windows Media MMR, в секции Setting Up Desktop and Application Pools документа View guide.
Поддержка HTML Access для приложений Hosted Apps
Теперь пользователи могут получать доступ к виртуализованным приложениям Hosted Apps через веб-клиенты HTML Access. Чтобы использовать эту возможность нужно скачать и установить HTML Access installer. Более подробно об этом рассказано в разделе To use HTML Access with Hosted Apps.
Скачать VMware View Horizon 6.1.1 можно по этой ссылке.
RSS
